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Applicants request review of the final rejection in the above-identified application. No 
amendments are being filed with this request. This request is being filed with a Notice of 
Appeal. The review is requested for the reason(s) stated below: 



This responds to the Office Action mailed on November 2. 2006 . 
Claims 1-20 are presently pending in this application. Applicants have made no further 
amendments to the claims. 



Claims 1-2, 4, 6-9, 12, 14-18 and 20 were rejected under 35 U.S.C. § 102(e) for 
anticipation by TumbUn et al. (U.S. 6,490,679). ). It is of course fimdamental that in order to 
sustain an anticipation rejection that each and every step or element in the rejected claims must 
be taught or suggested in the cited reference. 

More specifically, a claim is anticipated only if each and every element as set forth in the 
claim is found, either expressly or inherently in a single reference. Verdegaal Bros.v. Union Oil 
Co. of California, 814 F.2d 628, 631,2 USPQ 1051, 1053 (Fed. Cir. 1987). Additionally, "[t]he 
identical invention must be shown in as complete detail as contained in the . . . claim ." 
Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236, 9 USPQ 1913, 1920 (Fed. Cir. 1989). 
Emphasis added. Further, the elements must be arranged as required by the claims. 

Applicants would like to respectfiiUy reiterate that anticipation is only proper if "[t]he 
identical invention must be shown in as complete detail as contained in the . . . claim." 



REMARKS 



§102 Rejection of the Claims 
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Richardson v. Suzuki Motor Co,, 868 F.2d 1226, 1236, 9 USPQ 1913, 1920 (Fed. Cir. 1989). 

The Examiner has issued an anticipation rejection and not an obviousness rejection. 
Thus, the above law and analysis vis-a-vis the reference must be taken before such an 
anticipation rejection will be sustained. 

One continued point of disagreement with the Examiner appears to focus on whether the 
security non-extensible application is security aware and whether the security non-extensible 
application directly communicates with the NSIM (security module). 

The Examiner has asserted that the NSIM "intercepts" connection requests from the 
security non-extensible application. This term "intercepts" that appears in FIG. 12 at reference 
numeral 710 and at colunm 8 lines 22-25 is being used exclusively to support the Examiner's 
conclusion that the NSIM is not security aware. "Intercept" includes several definitions in 
Merriam- Webster ( www.m- w.com keyword "intercept"); one of which is to "gain possession of 
and another which is "to receive usually secretly." The usage of this term has to be considered 
within the fiiU context and arrangement of the Tumblin reference. 

When this is done it becomes clear what the true interaction between the security non- 
extensible application and the NSIM is. The Examiner's attention is directed to FIGS. 3-8; each 
of these very clearly show and discuss in the specification of Tumblin that the security non- 
extensible application includes an API to interact with the NSIM. Now it may be that the 
original source of the security non-extensible application makes calls to Winsock that get 
replaced with the "Unked" in API of the NSIM; but this just means that the source code may still 
remain the same but the actual executable module is forced to actually interact with the API of 
the NSM. Applicants' claims are directed to executable modules and not source code. As far as 
Applicants' are aware source code only is not patentable subject matter. So, from the source 
code perspective it may appear to an outside observer that calls were intercepted; but the entire 
disclosure indicates that what actually occurs is that the linked executable code for the security 
non-extensible application includes a direct call to the NSIM. So, the module that performs the 
processing is very security aware because the executable (module that performs the processing 
that the Examiner has to rely upon to defeat the claims) is explicitly linked to the API of the 
NSIM and does "directly" contact the NSIM. What the Examiner relies on is that to an outside 
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observer familiar with or viewing the source of the security non-extensible application may 
believe that the NSIM intercept a call; but the module being viewed is not the source it is the 
executable and that executable functionally includes a linked in call to the NSIM. Thus, the 
executable version of the security non-extensible application is in fact very security aware and 
does in fact make direct, specific, and linked in calls to the NSIM. 

To illustrate this point further, the Examiner's attention is directed to the following 
references within Tumblin: column 5 lines 14-24, a security non extensible program is linked to 
an API to replace that program's existing API to provide enhanced security; column 6 lines 19- 
24, the security non extensible program is linked to the API providing enhanced security; column 
5 lines 34-41, the NSIM and the security non extensible are linked together via the API; colunrn 
5 lines 41-5 1 each NSIM is capable of interacting with the security non extensible program or 
application to which it is linked; column 8 lines 10 through 17 even specifically states the 
security non extensible programs are "linked" to the NSIM via an API; and claim 1 states that the 
NSIM is linked to the application program and so does claim 4, 

In fact, the figures and the claims clearly state that the mechanism by which Tumblin 
achieves interaction or interception is to link into the application and API that calls the NSIM. 
The fact that Tumblin in passing uses "intercept" is inconsequential semantics that when the 
whole of Tumblin is read becomes clear and can be put in the proper context, which is fi-om the 
source's point of view it may appear to be intercepted but from the executable's point of view a 
very specific mechanism is used to interface the security non-extensible module and the NSEM 
and that is to substitute in an API that directly communicates with the NSIM. So, the executable 
actually and clearly and directly communicates with the NSIM via a "linked" in API call. 

This approach in Tumblin is different fi"om what Applicants have taught. There is no 
modification needed in Applicants' approach to the program (executing version); whereas in 
Tumblin an API has to be linked into the program or else Tumblin cannot work. Thus, 
Applicants continue to maintain that Tumblin is security aware and is not security xmaware. This 
is based on the fact that Tumblin is using a different arrangement and achieving its results in an 
entirely different manner where the program being extended is actually linked to an API of the 
NSIM. 
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An anticipation rejection cannot be sustained if the identical arrangement is not shown in 
the same manner. Tumbhn uses a different manner entirely, it links the NSIM via a common 
API to the executable of the program. Regardless of a passing use of a term "intercepting" the 
substance of the teaching of Tumblin cannot be ignored and the substance clearly indicates the 
NSIM API is linked into the security non extensible application. Thus, to say it is "security 
unaware" is not sustainable because it directly calls the NSIM via the linked in API. 

Applicants would like to remind the review Board that the Examiner issued an 
anticipation rejection (102) and not an obviousness rejection (103). The standard of review for 
102 is stricter than it is in 103 instances and in the instant case there is not adequate rationale in 
view of the Tumblin teachings to sustain the anticipation rejections of record. 

Accordingly, Applicants respectfully request that the review Board overtum the 
Examiner's present rejections and reinstate prosecution or permit the claims to issue. 

§103 Rejection of the Claims 

Claims 3 and 10 were rejected imder 35 U.S.C. § 103(a) as being unpatentable over 
Tumblin et al. in view of SSL-Talk List FAQ Secure Sockets Layer Discussion List FAQ vl.1.1 
("SSL-Talk List FAQ"). Claim 3 is dependent from independent claim 1 and claim 10 is 
dependent from independent claim 7. These dependent claims 3 and 10 are allowable if the 
independent claims from which they depend are allowable. Applicants submit based on the 
remarks above that they are in fact allowable and the rejections should be removed. 

Claim 5 was rejected under 35 USC § 103(a) as being unpatentable over Tumblin et al. in 
view of Samar (U.S. 6,304,974). Claim 5 id dependent from independent claim 1 and is thus 
allowable if claim 1 is allowable. Applicants submit that claim 1 is allowable and therefore this 
rejection should be withdrawn. 

Claims 1 1 and 19 were rejected under 35 USC § 103(a) as being unpatentable over 
Tumblin et al. in view of Novell NetWare Connection Enhanced NetWare 5 "What's Enhanced 
in NetWare 5." Claim 1 1 is dependent from independent claim 7 and claim 19 id dependent 
from independent claim 16; for the reasons above the anticipation rejections are insufficient as a 
matter of law for these independent claims; thus these claims should be allowed and their 
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rejections withdrawn. 

Claim 13 was rejected under 35 USC § 103(a) as being unpatentable over Tumblin in view of 
Microsoft Security Advisor SSL Specific WSAloctl Controls ("MS SSL Advisor"). Claim 13 is 
dependent from independent claim 7. Claim 13 is allowable if it is found that claim 7 is 
allowable. Applicants respectftiUy submit that as a matter of law the anticipation rejections 
cannot be sustained in their present form and thus claim 7 and 13 are allowable and the rejection 
of claim 13 should be removed. 



CONCLUSION 

Applicants respectfiiUy submits that all of the pending claims are in condition for 
allowance, and such action is earnestly solicited. The Examiner is invited to telephone the 
below-signed attomey at (513) 942-0224 to discuss any questions which may remain with respect 
to the present application. 

If necessary, please charge any additional fees or credit overpayment to Deposit Account 
No. 19-0743. 

RespectfiiUy submitted, 
BABER AMIN ET AL. 
By their Representatives, 

SCHWEGMAN, LUNDBERG, WOESSNER & KLUTH, P.A. 
P.O. Box 2938 
Minneapohs, MN 55402 
(513) 942-0224 

f) 




Date Januarv 3, 2007 By _/ 

Joseph P. Mehrle 
Reg. No. 45,535 
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Alexandria, VA 22313-1450 on this 3 day of Januarv 2007. 
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